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Abstract 


The Digital Communications Experiment (DCE) 
onboard the UoSAT-Oscar-1l spacecraft 
recently began a new phase of regular 
operations. Development and installation 
of enhanced store-and-forward message 
transfer software (MSG2) = capable of 200- 
kbytes transatlantic data transfer per day 
- is the second plateau in the DCE 
experimental program. This program is 
designed to gain experience with computer- 
based message systems in low earth orbit. 


The DCE is the first orbiting store-and- 
forward device to carry general amateur 
traffic on a continuing basis. The drafts 
for this paper were developed and edited by 
the collaborators in the USA and the UK 
using the spacecraft as the only means of 
communications. 


This paper provides information on _ the 
capabilities and the design of this system 
as well as some background information on 
the UoSAT-OSCAR 11 spacecraft. 


1.0 BACKGROUND 


The UO-11 spacecraft, also known as UoSAT- 
2, was designed and built at the University 
of Surrey in England during the second half 
of 1983. It was known as UoSAT-B until its 
launch from Vandenberg Air Force Base near 
Lompoc California in March, 1984. 


The possibility of flying a small store- 
and-forward messag xperiment onboard UO- 
11 was first discussed at a PACSAT design 


meeting in July 1983. Amateur groups in 
Dallas, Los Angeles, Ottawa, and Tucson 
immediately began work. A flight ready 
unit was turned over to the integration 
team at Surrey five months later, A 
partial account of this whirlwind 


development can be found in AMSAT's "Orbit" 
magazine number 18, March/April 84. 


1.1 The Spacecraft 


cuboid with 
58.5cm. 


The yori 
dimensions of 


spacecraft is a 
35.5cm x 35.5cm x 


There are solar cells on the four long 
faces, generating a total of 35 watts of 
power, which is stored ina 6-amp-hour, 


NiCd battery. Included in the complement 


of experiments ar 


STORE-AND-FORWARD SYSTEM 
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0 CCD camera with 384 x 256 pixel image 
capability with 128 levels of gray scale. 


(Geiger 
electron 


particle detectors 
multi-channel 


0 Three 
counters) and 
spectrometer. 


0 Space dust (micrometeorite) detector. 
o Magnetometer - to measure magnetic field 


and to determine spacecraft attitude. 


0 192kbytes CMOS memory for storage of CCD 
camera and particle/wave data. 


The spacecraft has three downlinks: 
145.825, 435.025, and 2401.5 MHz. The 145 
MHz downlink is usually on. The 435 MHz 
downlink is now regularly used for DCE 


operations. The 2.4 Ghz downlink is rarely 
used. 
The main spacecraft control computer - the 


On Board Computer (OBC) = is based on an 
1802 microprocessor with 48kbytes of static 
RAM. 


1.2 DCE Hardware 


= 


The Digital Communications Experiment (DCE) 


is an important experiment on uo-1ll -- 
establishing that store-and-forward 
communications in low-earth orbit is 
realizable and thus fulfilling one of the 
UO-11 mission objectives. The major goal 
of the DCE is to provide a software and 


hardware testbed for PACSAT-type store-and 
forward devices. To that end, it was 
designed to be as flexible as possible. 
The DCE is all CMOS and contains: 


0 An NSC-800 CMOS microprocessor using the 
280 instruction set. 


o Two 2 Harris HD-6402 UARTs. 

0 One 82C55 parallel port 

0 14k of 2kx8 static RAM, Harris 6516. 

0 16k of Harris 6564 16kx4 static RAM, 
using 12 bits to store 8 with single bit 


error detection and correction in hardware. 


0 64k of 8kx8 static RAM, Hitachi 6264LP. 


0 32k of 2kx8 static RAM, Hitachi 6116L. 
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0 512 bytes of Harris 6641 bootload PROM. 


This PROM hasan identical, command 
selectable backup device. 

0 command selectable clock speeds of °.9 
and 1.8 MHz. 

The DCE resides on three circuit boards 


in a standard UoSAT module box 
It draws 120ma 


which fit 
approximately 6" x 9" x 1". 
at +5 volts. 


The total DCE memory capacity is 126kbytes, 
bringing the total memory aboard UO-11 to 
366k -- far exceeding the total memory 
previously flown by amateur spacecraft. 


1.3 Early DCE Operations 


UO-11 DCE began its orbital operations on 


June 5, 1984. Initially, it supported 
spacecraft operations -- this unplanned 
activity made necessary by the post-launch 
failure in an uplink data communications 
path. UoSAT spacecraft have considerable 
redundancy in this area, and the problem 
could be bypassed by routing all VHF 


spacecraft communication through either the 
DCE computer or the spacecraft's main 
onboard computer (OBC). The DCE provided 
this bypass function in the initial months 
of spacecraft operations. Since that time, 
the software in both computers has matured 
sufficiently to perform the command bypass 
function while carrying out their other 
duties. The OBC carries out autonomous 
operational control of the spacecraft and 
its experiments, and also automatically 
determines and adjusts the satellite's 
attitude. The DCE is dedicated to the 
messag store-and-forward function. 


A prototype messag system, developed by 
Hugh Pett, VE3FLL, was used for a 
demonstration of low earth orbit store-and- 
forward capabilities at the Pacific 


Telecommunication Conference in Hawaii in 
January 1985. The demonstration was done 
by Hugh and Larry Kayser, WA3ZIA, with 
support by Harold Price, NK6K and Chris 
Wachs, WA2KDL in Los Angeles; and Martin 
Sweeting, G3YJO and the UoSAT team in 
Surrey. 


1.4 Current DCE Activities. 


MSG2, the current DCE software, was 
developed in November 1985 by Harold Price, 
NKOK, and Jeff Ward, K8KA, at the 
University of Surrey's UoSAT laboratory. 
Assistance in implementing the MSG2 ground 
segment on the BBC micro was provided at 
UoS by Michael Meerman, PA3BHF. The 
spacecraft automated control software, 
DIARY, which also permits DCE ground 
stations to command the downlinks and 
multiplexors, was written by Steve Holder 


(UoS). 


2.0 MSG2 SOFTWARE 
MSG2 supports the following features: 

0 Stores up to 96k bytes of message data. 
0 A single message can be up to 16k bytes. 


0 Up to 128 messages may be stored at one 
time. 


0 A partially downlinked message can be 
continued at a later time without repeating 
parts of the message already received. 


0 A partially uplinked message can be 


continued at a later time without 
retransmitting parts of the message already 
sent. 

ty) If a ground station looses’ positive 
control, the DCE will automatically revert 
to a known state after 2 minutes. The 


spacecraft DIARY program will also return 
the downlinks and data multiplexors to a 
known state after 15 minutes. 


0 The MSG2 protocol provides complete data 
transparency. 


ty) The ground station's transmit/receive 
changeover time is not a factor in 
communications. The ground station can be 


full duplex, half duplex using computer 
controlled (fast) switching, or half duplex 
using human (slow) switching. 


Restrictions in this version: 


0 Data transfer is in one direction at a 
time. Acknowledgments can be full duplex. 


0 Only one ground station can interact 
with the DCE at one’ time. The MSG2 
software provides the means to keep ground 
stations from accidentally violating the 
restriction. 


o The integrity of message data stored is 


not currently guaranteed as the message 
storage area of the DCE memory is not 
protected against externally induced 
errors. The program and non-message data 


are protected by hardware. 


These restrictions may be lifted in later 


implementations. 


MSG2 consists of three elements, a protocol 


specification, the MSG2 software running on 
the DCE, and several implementations of 
software for various computers which 
implement the MSG2 protocol for ground 
users. 


2.1 MSG2 Protocol 


The MSG2 protocol was design primarily to 
be easy to implement. Its only other goal 
was to provide the minimal message handling 
capability to PUT a message on the DCE, to 
GET one back, and to KILL a message no 
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longer required. 


As “easy to implement" dictated a single 
user approach, a LOGON and LOGOFF 
capability was added to keep two or more 
ground stations from starting message 
transfer operations simultaneously. 

Experimentation with minimal ground 
stations is planned; the MSG2 protocol was 
designed to accommodate this activity. 


Messages are broken into small (64 byte) 
blocks with CRC error detection. Once a 
message transfer is begun, message blocks 
can be acknowledged at any time, and in any 
quantity. This allows a battery powered 
station to reduce its transmissions by 
requiring only one acknowledgment for a 
message of any arbitrary number of blocks. 
Unacknowledged blocks are retransmitted in 
a "round robin" fashion. 


DCE blocks are acknowledged by sending a 
bit map frame. The bit map contains = one 
bit for each block in a message. Bits set 
to 1 represent unacknowledged blocks, and 
Os represent acknowledged blocks (Fig 1). 
The transmitting station continues to send 
the blocks indicated by 1 bits, until a 
bitmap is received with all bits set to 0. 


Figure 1. -- Example of an MSG2 Bit Map 
7654 3210 (1) 
00101000 (2) 
01234567 (3) 


(1) numbering of bits in bit map (MSB is 7) 
(2) bit map ack'ing all but blocks 2 and 4 
(3) blocks represented by bit map bits 


2.2 MSG2 Frame Format 


This section is not meant to provide a 
formal MSG2 protocol specification, but to 
outline the structure of the protocol and 
the frames used by it. Frame types may be 
added or removed as the protocol matures. 


Although there are several types of frames, 
they all share the following format: 


<10h><03h><cmd><cmd not><data length><data> 
<erce> 


Each byte is sent aS an asynchronous 
character with 8 data bits and no parity 
bit. Frames are preceded by several SYN 
bytes <1l6h> for modem and timing 
synchronization. 

Frame breakdown: 

<cmd> -- A single ASCII character 
specifying a DCE command. 

<cmd not> -- The inverse of <cmd>. This 


byte can be calculated by <CMD> XOR FFh or 
by 255 minus <cmd>. 


<data length> -- A single byte giving the 
length of the <data> portion, in bytes. 
Data length is between 0 and 128 bytes. 


<data> -- <data length> bytes of data. 
This data can be either ASCII characters or 
binary bytes. 


<crc> -- Two bytes of cyclic redundancy 
check. The CRC is a type of checksum, and 
it covers everything from <cmd> to the end 
of <data>, inclusive. 


In order to assure that <1l10h><03h>, the 
beginning of frame marker, does not get 
transmitted in the frame, all <lOh> bytes 
other than the one at the beginning of a 
frame are doubled. That is, during 
transmission, <10h> is converted to 
<10h><1Oh>. When receiving a frame, after 
the first <l10h><03h> has been detected, all 
<10h><10h> sequences should be converted to 
a single <l0Qh>. If a non-doubled <10h> is 
encountered in a frame, it is an error. 


2.3 MSG2 CRC 


Every frame transmitted by the MSG2- ends 
with a two-byte Cyclic Redundancy Check 
(CRC). The CRC is an error detection code, 
and if you use the CRC equation on a 
received frame, your two-byte answer should 
match the two bytes transmitted at the end 
of the frame. The CRC used by MSG2 is 
calculated using a modified CCITT CRC 
algorithm. A Z80 machine-language program 
showing how this is done is provided in the 
appendix. 


The CRC calculation includes all bytes from 
<cmd> to the end of <data>. The CRC 
calculation is done prior to doubling <10h> 
bytes and, by the receiver, after removing 
the extra <l0h>. 


2.4 Title Frames 


The DCE was required to "do something 
interesting" when it was. idle, i.e. not 
performing a function at the specific 
request of a ground station. To this end, 


MSG2 sends the first line of each active 
message on the downlink when it is idle. 
This line is the message "title" and 
usually contains at least the source, 
destination and subject of the message. 


Ground stations can see if they have any 
waiting traffic without interacting with 
the DCE by simply copying these title 
blocks. The OBC DIARY program currently 
switches the DCE onto the downlink for 30 


seconds at roughly 5 minute intervals. 


Title frames provide a way for stations not 
directly involved in DCE operations to 
monitor DCE activity. The <cmd> byte ina 
title frame is "T". The contents of the 
<data> portion of a title frame are are as 
follows: 
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Message number, 1 byte. If the first bit 


of this byte is set, the message is not 
complete, and the message title may be 
invalid. Message numbers for complete 


messages run from 0 to 127. 


Message length, 1 byte. This is the length 
of the message that is stored on the DCE, 


it is not the length of this title frame. 
Multiply this by 64 to get the message 
length in bytes. 

Call sign of station using DCE, 9 bytes of 


ASCII. If no one is using the DCE then 
this will be 9 blanks. 


Title of the message, the remaining 
<length> minus 11 bytes of the <data> 
field. This is taken from the first line 
of the message. The length referred to 
above is the FRAME LENGTH (which follows 
the inverted command). The 11 accounts for 
the message number, message length and call 
sign data. 


4 


The title for message number 0 - contains 
MSG2 administrative and status information. 
It currently contains MSG2 version number, 
a counter from the error detection and 
correction (EDAC) memory, the number of 
free memory blocks available, the number 
that will be assigned to the next message, 
a counter that is incremented every time 
MSG2 receives ae valid frame, an error 
indicator and an indication of which bank 
of RAM is active. Message 0 itself is used 
to download portions of the program 
variables, including a table of memory 
address where the EDAC circuits have 
corrected an error. 


2.5 Other Frames 


The above information and a short computer 


program will allow causal ground observes 
to monitor DCE activity. During actual DCE 
operations, however, several other frame 
types are used. The following command 


frames are used by DCE ground stations, and 
the list provides insight into the 
operation of the MSG2 mailbox. 


LOGIN tells the DCE the call sign of the 
ground station. 


LOGOUT frees the DCE for use by another 
ground station. Logout is automatic if the 
DCE does not hear the ground station for 


two minutes. 


PUT is used by the ground station to store 


= 


a message to the DCE. 


CONTINUE allows the ground station to 
continue (on another orbit) a PUT operation 
that was interrupted by LOS. 


a message from the 


GET is used to retriev 


DCE. 


KILL deletes a messag 


title- 
logging out the 


END resets DCE software to_ the 
display mode, without 
ground station. 


Thus, the DCE has all of the commands 
needed in a computer bulletin-board system. 


jE | 


3.0 DCE SOFTWARI 


The DCE MSG2 software is implemented in 280 
assembler code. It is in assembler for 
both size and speed, the DCE MSG2 runs in 
2.5k and supports full duplex operations at 
1200 baud on a 280 with a .9MHz clock. 


The program resides in the memory protected 
by hardware EDAC. Messages are stored in 
96k of non-protected memory. This memory 
is mapped into the upper 32k of the 280 
memory space. There are two 32k banks and 
two 16k banks. The banked memory is 
organiied as a linked list of 256-byte 
blocks. All of the banked memory is used 
except for the block in _ bank three 
containing location A5Flh, which has a bit 
that went bad shortly before launch. 
Messages consist of a linked list of memory 


blocks, unused blocks are kept ona free 
list. 

All of the link pointers for the memory 
blocks are kept in the memory protected by 


hardware  EDAC. Currently, blocks from 
deleted messages are returned to the top of 
the free list where they will be the next 
to be re-allocated. This tends to kept 


bank 1 in use and bank 4 empty. This will 
be changed in a future version. 

The banked memory is not currently 
protected against charged-particle induced 
soft errors. Algorithms are being 
developed to provide this memory with 


software EDAC in the future. In 60 days of 
monitoring, we have only seen three errors 
in the 16k of hardware-protected memory. 
It is hard to draw conclusions from _ this 
limited data, and the memory technology is 
not the same in the banked memory. 
Experiments are planned to gather data on 
soft errors in all parts of memory. 


3.1 Other MSG2 Functions 


The MSG2 software on the DCE supports two 
non-messag related functions. 


BYPASS = The DCE sends all characters 
received through the VHF uplink to the UART 


that leads to the spacecraft command 
system. This provides backup to_- the 
similar function performed by the DIARY 


the 1802 computer in case of 

or the need to completely 
The BYPASS software 
handler, 


program on 
1802 failure 
reload 1802 software. 
resides in the receive interrupt 
and therefore should perform the bypass 
function with high reliability no matter 
what the other levels of MSG2 software are 
up to. There is no way to disable the 
BYPASS. The BYPASS was made necessary by ¢ 
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failure in the VHF uplink facility shortly 
after launch. 


function washes any 
errors out of the 


MEMWASH - This 
accumulated single-bit 
hardware EDAC memory by reading a location 
and writing it back. A different memory 
byte is fetched and stored onc on ach 
trip through the main loop of the software, 
which occurs at least once every 9.2ms. 
All of the EDAC memory is checked at least 
once every 150 seconds, this number might 
be 10 to 100 times faster, depending on 
uplink activity. 


A third function under development is the 
gathering of information on soft memory 
errors in the unprotected areas of memory. 
This is to further the DCE's role in 
gathering engineering data used for PACSAT 
development as well as to provide a high 
level of data integrity for messages stored 
onboard the DCE. 


4.0 MSG2 GROUND STATION SOFTWARE 


The MSG2 protocol provides a small number 
of basic features: logon, logoff, put, get, 


and kill. The ground station software 
supplies additional “user friendly" 
facilities. Such features include 
remembering the start point for partial 
messages, providing wildcard or multiple 
file transfer, automatic logging, and 
providing antenna pointing cues; these 
features are not part of the basic set of 
functions, but make the DCE easier to use. 


particular 
station's 


The features available at any 
ground station depend on that 
hardware. 


5.0 MESSAGE FORMATS 


MSG2 is a data-transparent system, i.e. 
messages are stored as a single string of 8 
bit bytes. Message content does not effect 
and is not effected by communication 
through MSG2. Most messages, however, will 
follow a fixed format for their first line. 
The first line is defined as the text up to 
the first <cr>, or 116 characters. This is 
the part of the message that is sent on the 
downlink in title blocks. 


5.1  Person-to-Person Messages 


The following format is used for standard 
messages: 

To:<call> De:<call> Re:<title> 

The call can be up to 9 characters. There 


are no spaces after the colon in any field. 
For example: 
To:GO/K8KA De:NK6K Re:Software updates 


fields are the call signs 
A future command 


The To: and De: 
of DCE ground stations. 


in MSG2 will permit messages in this format 
to be searched by To: field and downlinked 
in a group. The format is flexible, and 
fields may be added to it if the DCE is 
used for other than direct ground station 
to ground station data transfer. 


6.0 THE RWITIRE OF THR DCE 


Several hundred kbytes of data have 
traveled between UoSAT headquarters in 
Surrey (UK) and NK6K in Los Angeles (USA) 
on the DCE. MSG2 ground station and 
satellite software works efficiently and 
reliably. While much of the future use of 


DCE store-and-forward capability depends on 
radio-regulatory matters beyond our 
control, the DCE has successfully proven 
that store-and-forward communications using 
a satellite in low-earth orbit can be 
carried out routinely. Tt has put us ina 


position to make informed design decisions 
while working an a proposed dedicated 
store-and-forward spacecraft. 


The limited memory available on UOQ-11 and 
the fact that DCE activities consume 
bandwidth on the UoSAT-11 command uplink 
and general downlink dictate that only a 
limited number of selected ground stations 
will take part in future DCE 
communications. These ground stations will 
be chosen such that, regulations 
permitting, each can serve aS a gateway -- 
delivering amateur radio news and and 
technical information to stations outside 
of the DCE ground station network. 


for an East Coast North America 
gateway is in place and should be 
operational by the time this sees print, 
A station will be brought on the air soon 
in New Zealand. Discussions are under way 
for stations in Australia and Japan. The 
DCE is ready now to serve as an effective 
link between the amateur radio  service’s 
far flung packet radio networks. 


Equipment 


7.0 SUMMARY 


The DCE project was begun as an opportunity 
to gain experience in the design, 
construction, and orbital operation of 
space -based large-memory store-and-forward 
message relay satellites. The parts used 
in its construction are giving us data on 
the suitability of high density non- 
specialized memory devices and 
microprocessors (i.e. inexpensive) in low 
earth orbit, which is directly applicable 
to future amateur space projects. The 
coming months will give us experience 
scheduling gateway operations to maximize 
data volume in a worldwide network of 
ground stations. 


exists now to move 114k 
from a single ground 


The capability 
bytes per day to or 
station. 

writing MSG2 


The experience gained from 
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operations, and 
issues will be 


managing DCE 
regulatory 


software, 
dealing with 


of great use when the mailbox on  JAS-1 
becomes operational and when design teams 
set to work on PACSAT -- an amateur radio 
satellit dedicated to store-and-forward 
communications. 
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Appendix 2 - DCE CRC algorithm. 


The routine below can be used to compute 
the checksum for reception of DCE frames. 
The HL register is cleared before the first 
byte is received. Each byte is acted on in 


turn. When all bytes have been 
checksummed, the result is compared against 
the received checksum. The L register 
contains the first byte received, the H 


register the second. 


9 
3 COMPUTE CRC ON A, INTO HL 
’ 
CKSUM: 
LD B,8 
LD C,A 
CRC2: 
LD A,C 
RLCA 
LD C,A 
LD A,L 
RLA 
LD L,A 
LD A,H 
RLA 
LD H,A 
JR NC ,CRC4 
LD A,H 
XOR 10H 
LD H,A 
LD A,L 
XOR 21H 
LD L,A 
CRC4: 
DEC B 
JR NZ ,CRC2 
RET 
In using this program on DCE frames, 
remember that the CRC covers all bytes from 


the <cmd> to the end of the <data> segment, 
inclusive,' It does not include the CRC 
itself, or the leading <10h><03h> bytes. 
Also, CRC calculation is done prior to 
doubling <10h> bytes and, by the receiver, 
after removing the extra <lOh>. To check 
your CRC program, CRC check the characters 
"TEST MESSAGE". The result should be CRC 
bytes L=253 and H=223. 253 would be the 
byte transmitted or received first. 
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